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ABSTRACT 


A- 

A  heuristic  approach  for  planning  multiple  resource  workloads 
in  project  networks  is  discussed,  with  particular  attention 
to  ship  overhaul  planning.  Projects  are  modeled  using  a 
critical-path-analysis  activity  network.  Activity  resource 
requirements  are  taken  as  given  and  activity  loading  is  assumed 
to  be  constant.  Activity  duration  variables  are  defined  which 
then  determine  the  demand  rates  per  resource  per  activity. 

An  iterative  nonlinear  programming  procedure  assigns  activity 
durations  (and  consequently,  activity  resource  demand  rates)  to 
minimize  resource  peaking  subject  to  meeting  project  due  dates. 
Computational  experience  is  described  for  application  to  a 
major  ship  overhaul. 
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I.  Introduction  and  Scope  of  the  Problem 

Production  activity  in  a  naval  shipyard  consists  of  a  variety  of  large  ship  overhaul  projects. 
Each  of  these  projects  requires  labor  input  in  the  tens  or  even  hundreds  of  thousands  of  man- 
days  from  among  20  different  trade  shops.  Project  durations  range  from  3  months  to  2 {/i  years. 
Manpower  loading  on  a  ship  overhaul  is  typically  very  peaked,  and  there  is  competition  among 
various  projects  for  manpower,  dry  docks,  and  other  key  resources.  The  planning  and  schedul¬ 
ing  of  projects  so  as  to  meet  target  completion  dates  while  maintaining  high  levels  of  yard  pro¬ 
ductivity  is  a  challenging  management  problem. 

In  current  practice,  the  problem  is  decomposed  into  two  stages.  First,  an  aggregate 
scheduling  effort  is  undertaken,  in  which  the  “rough"  scheduling  of  projects  is  made.  In  this 
effort,  starting,  ending,  and  a  few  intermediate  milestone  dates  are  established  for  each  project. 
The  goal  of  aggregate  scheduling  is  to  determine  milestone  dates  which  are  timely  but  feasible, 
considering  projections  of  available  production  manpower  and  dry  docks. 

Detailed  information  regarding  resource  and  duration  requirements  for  each  project  would 
be  desirable  to  accomplish  aggregate  scheduling.  But  only  very  aggregate,  preliminary,  informa¬ 
tion  is  currently  available  to  planners.  A  time  history  of  the  total  man-days  per  working  day  is 
estimated  from  past  experience  for  each  project;  by  setting  start  dates  for  each  project,  these 
histones  may  be  summed  to  estimate  the  total  man-day  history  on  the  yard.  By  trial  and  error, 
milestone  dates  are  developed  for  which  the  total  load  history  is  comparable  to  the  projected 
available  work  force,  and  dry  dock  conflicts  are  avoided.  I  See  Exhibit  1.)  This  load  information 
is  not  broken  down  by  labor  shop,  so  that  shop  load  infeasibilities  may  still  arise. 

In  the  second  stage,  detailed  project  scheduling  of  small  component  production  activities 
known  as  key— ops  is  undertaken.  The  specification  of  these  activities,  numbering  in  the 
thousands  for  each  overhaul,  may  require  a  year  or  more.  A  critical  path  network  is  then 
developed  consisting  of  the  key-op  activities,  which  are  then  scheduled  using  critical  path 
methods  (CPM).  In  the  scheduling  effort  network  slack  is  uniformly  allocated  among  activities, 
which  tends  to  reduce  the  project's  peak  resource  loads.  See  [31  for  a  discussion  of  CPM  and 
resource  load  leveling  methods.  See  Exhibit  2  for  an  example  of  a  key-op  description. 

Milestone  dates  and  key-op  schedules  are  distributed  to  line  (shop)  production  manage¬ 
ment,  which  is  responsible  for  the  day-to-day  allocation  of  working  crews  and  job  supervision. 
In  practice,  adherence  to  key-op  schedules  is  rare,  but  observance  of  milestone  dates  is  accom¬ 
plished  where  feasible.  In  a  sense,  line  management  accomplishes  its  own  version  of  resource 
leveling  by  varying  crew  sizes  and  job  assignments. 

It  is  our  opinion  that  aggregate  scheduling  techniques  utilizing  more  detail  than  now  used, 
coupled  with  scheduling  techniques  for  individual  projects  based  on  less  detailed  activity 


EXHIBIT  I 
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EXHIBIT  2 

EXAMPLE  OF  KEY- OP  ACTIVITY 

ACTIVITY  16662-26301-603  INSTALL  SHAFT  LUBE  PUMPS 
DURATION:  15  DAYS 

SHOP  HOURS  REQUIRED 

SHOP  5  (SHIPBOARD  MECHANICAL)  64  MAN  HOURS 

SHOP  7  (ELECTRICAL  CABLES)  8  MAN  HOURS 

SHOP  8  (PIPEFITTERS)  48  MAN  HOURS 


..  v-< 


definition  than  now  pursued,  would  be  valuable.  Shop  capacities  should  be  explicitly  treated  in 
aggregate  scheduling.  Work  scheduling  should  not  be  done  at  the  kev-op  level  of  detajJ,  Since 
such  fine  scheduling  is  largely  ignored  in  actual  operations.  An  Operations  Research  model 
used  in  shipyard  project  scheduling  should  assign  work  in  components  more  consistent  with  the 
schedule  constraints  perceived  by  line  management.  It  should  also  reflect  management's  flexi¬ 
bility  to  vary  crew  sizes  assigned  to  activities,  as  opposed  to  the  mere  scheduling  of  component 
activities,  in  efforts  to  level  resource  loads. 

The  development  of  improved  aggregate  scheduling  techniques  is  deferred  to  a  subse¬ 
quent  paper.  In  this  paper,  new  techniques  for  individual  project  scheduling  in  a  shipyard, 
motivated  by  the  above  discussion,  are  investigated. 


II.  Construction  Project  Model 


The  model  presented  here  was  originally  formulated  in  [2]  and  (4j.  We  present  a 
simplified  version  of  it.  The  construction  project  is  modeled  as  a  collection  of  component 
activities  A  utilizing  a  set  K  of  exogenous  resources.  The  dependencies  among  activities  are 
represented  by  an  activity-on-arc  CPM  network.  Given  are  a,k ,  the  required  amount  of  resource 
k*K  to  complete  activity  teA .  and  d,  ^0,  the  minimum  duration  of  activity  teA .  Let  .V,  a 
subset  of  A,  be  the  set  of  activities  requiring  non-zero  resources,  i.e..  a,k>Q  for  some  keK. 
Instantaneous  application  of  resources  is  not  possible,  hence  d,>0  for  f*N .  In  the  following 
sections,  activities  are  assumed  to  belong  to  A ,  and  resources  to  K ,  unless  otherwise  indicated. 

Let  ^  )  and  tS(r},  *  •  ,/  4.)%  where  r  is  a  vector  of  time  assignment  vari¬ 

ables  such  that  t  ^  d.  The  rate  of  application  of  resource  k  to  activity  / € .-V ,  a.k/ 1,,  is  modeled 
as  constant  between  the  start  and  finish  times  of  activity  i.  This  represents  a  constant  crew 
assignment  to  each  activity  /€;V  The  crew  size  is  determined  by  the  activity  time  assignment 
r.,  the  decision  variable  for  each  activity. 


For  a  given  time  assignment  vector  t  let  CPbfit ’)  denote  the  standard  CPM  scheduling 
computations  of  early  (late)  start  and  finish  time  and  total  activity  slack.  Consider  CPMld) 
The  computations  determine  the  minimum  project  duration.  T.  and  for  each  activity  t ,  us 
slack,  S..  An  activity  /  is  critical  if  it  is  on  a  critical  path,  i.e.,  5,-0.  If,  on  the  other  hand, 
5,  >0  then  activity  /  could  operate  for  a  longer  period  of  time,  using  less  resources  per  unit  of 
time  (if  /€.V),  without  delaying  the  project  beyond  T. 


Let  a  slack  path  be  defined  as  a  maximal  length  chain  of  slack  activities.  In  general,  the 
total  slack  of  a  given  slack  path  can  be  allocated  among  the  activities  on  that  path  whereby  all 
these  activities  become  critical.  A  time  assignment  vector  that  eliminates  all  slack  from  the 
slack  subnetwork ,  i.e.,  the  subnetwork  of  slack  activities,  is  said  to  be  critical.  Let  \r  be  the  set 
of  critical  time  assignment  vectors. 
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III*  Resource  Leveling 

Given  lime  assignment  vector  i  and  CP.V/G  i.  a  load  history  can  be  computed  lor  each 
resource.  (This  assumes  rounding  of  non-mteger  time  assignments  t  )  If  f  is  critical  then 
CPMit  )  uniquely  determines  the  resource  load  histories.  If  not,  activity  early  <or  late)  starts, 
for  example,  could  determine  the  schedule. 

For  ZccA,  let  t\(A)  be  the  required  capacity  of  resource  A\  defined  as  the  maximum  load 
over  all  time  periods  /.  \  Let  pk  be  the  cost  of  maintaining  a  unit  of  capacity  of 

resource  k  for  the  duration  of  the  project. 

We  seek  to  minimize  over  A,,  the  set  of  all  critical  time  assignment  vectors  t. 

K  t  A 

In  (21  this  problem  was  recognized  as  combmatonaily  too  complex,  and  a  heuristic  procedure 
was  proposed  in  an  effort  to  obtain  a  near  optimal  solution.  This  paper  presents  an  improve¬ 
ment  of  the  procedure. 

A.  Peak  Pricing  Procedure 

A  sequence  of  problems  is  considered  in  which  only  the  activities  operating  in  time 
periods  where  resource  loads  are  "close’*  to  capacity  c\U)  are  charged  for  their  contribution  to 
the  capacity. 

Let  some  time  assignment  vector  t  and  the  corresponding  load  histories  be  given.  For 
each  AsA.  define  the  peak  intervals  A  as  the  set  of  time  periods  m  which  the  load  of  resource 
k  is  within  a  specified  percentage  3  of  ckU  )  Also,  let  /,  be  the  subset  of  A  in  which  activity 
/e.V  operates.  Of  course,  activity  t  may  operate  partially  or  completely  outside  A  Note  that 
ls  a. k(  is  the  amount  of  resource  A  applied  to  acuvity  /  in  A.  Finally,  let  /*  S|  lh !/!  A  i  be 
the  fraction  of  A  in  which  activity  /€.V  is  active.  (The  dependence  on  i  has  been  suppressed 
in  the  notation  A  *  t\.)  In  [2],  the  fraction  t  s  was  approximated  by  a  0/1  coefficient,  that 

is.  / ,  —  1  if  and  only  if  /  operates  in  A 

The  capacity  t )  can  be  approximated  as  follows: 


fatal  amount  of  resource  k  applied  m  A 
size  of  A 


=  i  \(t) 


Exhibit  3  depicts  the  above  relationships  graphically 
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If  /,*(/),  as  a  function  of  r,  were  readily  computable  we  could  perform 


mm 

A*  A.'  «V  *' 


to  obtain  an  approximation  of  the  minimum  of  (f ).  This  is  not  the  case,  so  an  iterative 

k*K 

scheme  is  proposed. 

Let  some  initial  time  assignment  vector  /  (for  example  d)  be  given. 

Step  1.  Perform  CPMW)  and  compute  the  resource  load  histories. 

Step  2.  Compute  cK(t  )  for  all  k.  If  no  improvement  has  occurred  in  ).  stop. 

K  t  K 


Otherwise,  determine  IK  and  /*  for  all  y«/V,  ktK. 


Step  3. 


n  J  *A  . 

P,  min  2.A2. — : — 

k*  K  it  V  ' 


Let  ( *  be  an  optimal  solution  to  />, . 

Set  r  — f*  and  go  to  Step  1. 

B.  Optimization  Problem  Formulation 

The  mathematical  program  P,  can  be  formulated  as  a  convex  objective  subject  to  linear 
constraints.  Transformations  of  t  allow  \M  the  set  of  critical  time  assignment  vectors,  to  be 
represented  in  two  ways. 

/.  Slack  Atlocaaon  Variables:  Let  s  S  t—d,  s  =  (sj  *  *  *  ,s  ).  Then  s:  is  (he  slack  allo¬ 
cated  to  activity  /  given  the  time  assignment  t  ^  d. 

Let  A,  be  the  set  of  slack  allocation  vectors  s  satisfying 

for  all  slack  paths  it 

C  •  X.5'  “  s*ac^  Pat^  77  jn  the  s|ac|^  subnetwork 


s.  -  0 


5  0 


for  all  critical  activities 


Then  tt\,  if  and  only  if  s«.\s.  Problem  P,  becomes 


n  J  A 

P:  mm  IaI—  J«A, 

KtK  it  \  5 


Let  s*  be  an  optimal  solution  to  P,.  Then  / ’  -  s'+d  is  optimal  for  Pr.  (This  formulation  was 
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presented  in  [2]  with  ftk  approximated  as  a  0/1  coefficient.) 

The  variables  s,  for  all  critical  activities  /  can  be  excluded  from  the  problem.  Further¬ 
more,  consider  all  slack  paths  which  have  only  one  element,  i.e.,  an  activity  /  by  itself.  If  / 
does  not  occur  in  any  other  slack  path  then  s,  can  be  set  to  its  slack,  S  ,  thus  eliminating  a  con¬ 
straint  and  a  variable.  (See  Exhibit  4a  for  an  example  of  this.) 

The  number  of  linearly  independent  slack  path  constraints,  nSP .  cannot  exceed  the 
number  of  slack  allocation  variables,  that  remain,  and  may  be  considerably  smaller  (See 
Exhibit  4b). 

The  objective  function  coefficients  in  P,  (called  peak  prices)  will  be  non-zero  if  and  only 

if  £/*  a*  >  0. 

UA' 

Let  Sit  )  be  the  set  of  activities  with  non-zero  peak  prices,  given  time  assignment  vector  t'. 
Slack  allocation  variables  for  activities  not  in  .V(r  )  can  be  eliminated  by  rewriting  the  constraint 
in  Cs  for  slack  path  t  as 

£  5.  <  slack  of  path  it  . 

>tn 

» ♦ .  V  ( r  i 

Cs  is  thereby  reduced  in  size.  However,  the  slack  of  path  tt  that  is  not  allocated  in  the  optimal 
solution  of  P,,  if  non-zero,  must  somehow  be  allocated  to  the  excluded  activities  on  tt  to 
obtain  a  complete  CPM  schedule  and  thus  derive  the  load  histories.  (These  allocation  decisions 
were  made  implicitly,  and  arbitrarily,  in  the  original  formulation  Ps .)  Scheduling  the  excluded 
activities  could  be  done,  for  example,  at  early  (or  late)  starts  with  minimum  time  assignments. 
The  resulting  load  histones  will  certainly  be  influenced  by  these  slack  allocation  decisions. 

2.  Event  Time  Variables:  Let  V  be  the  set  of  network  nodes  (events)  and  let  (w(/).H/M 

be  the  ordered  pair  of  nodes  representing  arc  (activity)  i.  Let  rS(r, . r  {  )  be  an 

event  time  vector .  where  rt  is  the  point  in  time  at  which  node  v  is  reached.  Let  \.  be  the  set 
of  event  time  vectors  satisfying 

C.  ;  rl(l(  -  rwtl)  3*  d,  for  all  /c/f 

rk  -  r\  for  all  nodes  v€  ^  on  a  critical  path. 

where  r is  the  critical  node  (event)  time  of  i\  as  derived  from  CPMid).  C.  is  similar  to  the 
standard  CPM  linear  programming  formulation.  (See,  for  example,  [3 1 )  Then  /€  \,  if  and 
only  if  r€.\..  Problem  P,  becomes 

P-:  min  - - -  •  *«  A- 

k*  K  *  N  *  k  *  <  f  » 1  •  ’ 


EXHIBIT  4 


(a)  Single-Element  Slack  Paths 

Activity  i  constitutes  a  "single-element  slack 
path."  Its  slack  can  be  pre-allocated. 


(b)  Redundant  Slack  Paths 


This  subnetwork  of  S  slack  activities  gives  rise  to 
16  slack  path  constraints  (equalities) ,  of  which 
only  8  are  linearly  independent. 
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Let  r *  be  an  optimal  solution  to  Pr.  Then  /,* —  tuIi/  is  optimal  for  P, . 

The  event  time  variables  rv  for  critical  nodes  v  can  be  excluded  from  the  problem. 
Furthermore,  constraints  for  all  activities  /  such  that  u(i)  and  v(/)  are  critical  nodes  (as  shown 
in  Exhibit  4a)  become  redundant. 

C T  then  consists  of  nSA  inequalities  in  nss  variables,  where  ws,v,  the  number  of  slack 
nodes,  is  usually  considerably  smaller  than  nSA .  Also,  nSl v  <  nSP. 

In  its  most  compact  form,  C,  consists  of  nsf>  inequalities  in  |iV(/')|  variables,  plus  non¬ 
negativity  constraints.  Exhibit  5  displays  the  constraints  sets.  The  use  of  P,  or  Pr  will  depend 
on  the  way  in  which  the  linear  constraint  set  is  imbedded  in  the  non-linear  programming  algo¬ 
rithm.  If  the  algorithm  uses  the  dual  constraint  set  in  an  imbedded  linear  program  (see,  for 
example,  [1])  then  P.  will  most  likely  have  the  LP  basis  of  smallest  size. 


C.  Procedure  Termination  and  Cycling 

The  allocation  of  remaining  slack  for  activities  with  zero  peak  prices  is  made  arbitrarily  in 
both  formulations.  This  is  a  symptom  of  the  inherent  weakness  of  the  Peak  Pricing  Procedure. 
Since  /,*  does  not  change  within  an  iteration  as  the  time  assignments  (or  their  transformations) 
do,  slack  is  allocated  without  feedback  on  the  resulting  shift  in  resource  loads.  A  procedure  can 
be  imagined  where  feedback  is  more  frequent,  at  the  price  of  more  frequent  load  history 
recomputations. 

In  general,  no  guarantee  of  improvement  in  each  iteration  of  the  procedure,  let  alone  con¬ 
vergence  to  optimality,  can  be  given.  The  new  resource  peaks  will  tend  to  be  outside  the  previ¬ 
ous  peaks  and  may  even  by  higher  than  before.  In  our  experience  a  commonly  occurring  situa¬ 
tion  was  the  cycling  between  two  different  sets  of  peak  loads.  The  following  modification  to  the 
procedure  was  made  to  cope  with  this  problem. 

Given  time  assignment  vectors  z1,/2,  •  •  •  jL  from  previous  iterations,  define 

L  i 

/A(/‘,  •  ■  ■  JL)^^ak,/lk(tl)  ,  where  au>0,  £au-l. 

/-i  /-i 


An  obvious  choice  for  akt  is 


a  4/ 


Cfc(f') 


which  assigns  weights  to  resource  capacities  according  to  their  relative  contribution  over  all  L 
iterations. 
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The  coefficients  J\K  depend  of  course  on  the  definition  criterion  for  lk .  The  criterion 
could  vary,  for  example,  from  resource  to  resource,  or  from  iteration  to  iteration,  depending  on 
the  particular  resource  load  pattern.  Some  experience  with  different  criteria  is  described  below. 

D.  Capacity  Requirements  vs.  Project  Delay 

The  formulations  Ps  and  P.  can  be  adapted  to  study  the  trade-off  between  resource  capa¬ 
city  cost  and  project  delay.  Let  y(  T)  be  some  project  opportunity  cost  as  a  function  of  the  vari¬ 
able  project  duration  T.  For  simplicity  of  exposition,  we  assume  .t  to  be  the  only  starting  node 
and  y  the  only  finishing  node  in  the  network. 

Ps  becomes 

"”"IaX  T7T  +  y'r' 

ktk  t  V  ^ UI 

for  all  paths  tt  from  .v  to  v 
S‘L  <E»S'  *  '  in  the  network 

htt  >tir 

s  3s  0  . 

and  P.  becomes 

—  +  y  IT) 

ktk  *  V  *  v  <  *  I 

•  i . , i  —  Tutn  for  all  / 6.4 


Since  the  durations  of  previously  critical  activities  are  no  longer  fixed,  the  variables  and  con¬ 
straints  associated  with  them  can  no  longer  be  excluded  a  priori. 
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IV.  Applications  and  Computational  Experience 

A.  Network  and  Data 

The  original  key-op  network  for  a  naval  ship  overhaul  with  about  1200  key-ops  using  20 
different  labor  types  (resources)  was  selected  for  testing  of  the  new  techniques.  Parallel  or 
series  key-ops  that  had  similar  work  content  (labor  type)  and  dealt  with  the  same  technical  sub¬ 
system,  e.g.,  removal  of  various  components  of  the  main  steam  system,  were  grouped  to  form 
one  aggregate  activity.  Attention  was  paid  to  combine  key-ops  with  similar  resource  application 
rates.  In  this  manner,  a  more  aggregated  network  was  developed,  consisting  of  316  activities 
using  resources  and  75  other  activities  (milestones,  dummy  activities,  time  lag  activities).  The 
largest  twelve  labor  shops  were  retained  with  a  total  of  32,600  man-days  of  labor  requirements. 
See  Exhibit  6  for  a  list  of  shops  and  the  labor  requirements  per  shop.  See  Exhibit  7  for  an 
example  of  an  aggregate  activity. 

The  minumum  duration  of  each  aggregate  activity  was  computed  as  the  maximum  of  the 
path  lengths  of  the  key-op  activities  which  comprised  the  aggregate  activity.  The  project  dura¬ 
tion  was  21 1  days. 

In  the  absence  of  good  capacity  cost  estimates,  the  cost  coefficients  p*  were  set  to  1  and 
the  objective  became  to  minimize  the  sum  of  the  shop  capacity  requirements. 

The  shops  interact  quite  strongly.  This  is  most  evident  in  the  case  of  shops  4  and  5  Shop 
5  is  responsible  for  removal,  re-installation.  and  testing  of  mechanical  subsystems.  Shop  4  per¬ 
forms  the  on-shore  repair  of  the  subsystem  components.  The  load  pattern  of  shop  5  shows  two 
regions  of  peak  labor  requirements:  one  during  the  removal  phase,  the  second  Junng  re- 
installation.  The  peak  of  shop  4  lies  in  the  valley  between  shop  5%s  peaks.  (See  Exhibit  8.) 

The  slack  path  formulation  of  the  optimization  step  was  chosen.  To  reduce  the  size  of  the 
problem  those  activities  whose  labor  requirements  per  shop  per  day  (a^/d. )  did  not  exceed  one 
man-day  were  excluded  from  the  optimization  problem  Ps.  It  was  reasoned  that  slack  allocation 
to  these  activities  would  have  reduced  resource  capacities  only  insignificantly  Ninety-eight 
activities  with  3,600  man-days  of  labor  requirements  (11%  of  total  requirements)  were  thus 
excluded.  The  constraint  set  C5  was  reduced  to  170  inequalities  in  168  variables.  An 
accelerated  feasible  conjugate  direction  algorithm  due  to  [I)  was  used  to  solve  the  problems  Ps. 

B.  Experiments 

(a)  Early  experiments  were  performed  with  the  0/1  coefficients  )\  and  various  peak  inter¬ 
val  threshholds  ranging  from  2%  to  15%.  Sequences  of  iterations  with  0  varying  from  itera¬ 
tion  to  iteration  led  to  inconclusive  results.  A  value  of  /i-5%  was  then  chosen  for  experiments 
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EXHIBIT  6 

LIST  OF  LABOR  SHOPS 


Numbers 

Name 

Project  Labor 
Requirements 
(man-days) 

I 

Structural  Group  I 

1330 

2 

Structural  Group  II 

1390 

3 

Weld  &  Burn 

2290 

4 

Mechanical  Group- Shop 

4310 

5 

Mechanical  Group-Shipboard 

5110 

6 

Boilermakers 

2310 

7 

Electrical 

3040 

a 

Pipe-fitting 

5910 

9 

Electronics 

2800 

10 

Shipwright 

640 

11 

Painting 

3000 

12 

Rigging 

540 

Total  Project  Labor 
Requirements 

32670 
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EXHIBIT  7 

EXAMPLE  OF  AGGREGATE  ACTIVITY 

Aggregate  Activity:  Inspect  and  Remove  Fuel  Oil  System 

Components 

Principal  Shops  Involved:  Shop  8  -  Pipefitting 
Total  Labor  Requirements:  93  Man-days 
Minimum  Duration:  20  days 


Component  Key-ops.- 


Key-op 

No . 

Name 

Minimum 

duration 

(days) 

Total  Labor 
requirements 
(man-days) 

105 

Inspect  Piping 

8 

10 

120 

Remove  Relief  Valves 

3 

2 

121 

Remove  Strainers 

10 

30 

140 

Remove  Pumps 

6 

8 

160 

Remove  Controllers 

2 

2 

320 

Flush  System 

10 

20 

321 

Flush  Strainers 

10 

30 

93 

*summed  over  all  shops 


Key-op  Subnetwork 


Legend : 

(2)  -  minimum  duration 
160  -  key-op  number 


longest  path 

*  minimum  duration  for  aggregate 
activity 


18 


<b)  and  (c). 

(b)  Initial  load  histories  were  computed  from  CPMid)  with  an  early  start  schedule.  Then 
the  slack  of  all  single-element  paths  was  allocated  las  described  in  Section  III.B.).  which  yielded 
an  objective  improvement  of  12n/o.  The  improved  definition  of  /a  used  to  compute  peak 
prices  for  subsequent  iterations  of  the  Peak  Pricing  Procedure.  Initially,  four  iterations  were 
performed  in  succession.  Pairs  of  successive  iterations  showed  cycling  behaviour.  Multiple 
iteration  weighting  using  iterations  1  and  2,  and  3  and  4,  was  tried.  The  iteration  with  weighted 
peak  prices  from  iterations  l  and  2  produced  the  best  results  thus  far,  an  improvement  of  31% 
over  the  initial  solution.  (See  Exhibits  9  and  10.)  Further  iterations  and  weightings  did  not 
improve  the  solution. 

(c)  To  test  the  effect  of  different  initial  load  histories,  a  late  start  schedule  from  CPMid) 
was  used  with  load  patterns  markedly  different  from  the  early  start  schedule.  As  before, 
single-element  path  slack  was  pre-allocated.  The  first  iteration  produced  a  solution  very  close  to 
the  best  result  of  (b).  Individual  shop  capacities  are  similar  in  size  (see  Exhibit  9)  and  the  load 
patterns  have  similar  shape  (See  Exhibit  1 1  for  the  case  of  shop  8.) 

(d)  By  setting  100%,  the  objective  function  of  Ps  becomes 


K*  K  *  N 


s,+d, 


so  that  Ps  can  now  be  stated  as  minimizing  the  sum  of  the  resource  application  rales  over  all 
activities.  The  solution  obtained  was  quite  good  compared  with  (b)  and  (c).  (See  Exhibit  9  for 
labor  requirements  by  shop,  and  Exhibit  1 1  for  a  comparison  of  load  patterns  of  shop  8.) 
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XPLRIMENTAL  RESULTS 
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EXHIBIT  10 


Experiment:  (b) 

SEQUENCE  OF  LOAD  KISTORIES-SiiOP  5 


After  Allocating  Slack  of 
Single-Element  Slack  Paths 

After  Iteration  1 

After  Iteration  2 

After  Weighting  Peaks  of 
Iterations  1  and  2 


EXHIBIT  II 


COMPARISON  OF  SHOP  8  LOAD  HISTORIES 


V.  Summary  and  Analysis  of  Results 

The  development  of  new  techniques  for  leveling  resource  loads  of  individual  overhaul 
projects  in  a  shipyard  has  been  reviewed.  The  techniques  exploit  the  crew  size  flexibility  avail* 
able  to  management  in  selecting  time  durations  for  aggregated  activities. 

Careful  development  of  the  overhaul  data  is  mandatory.  Activity  labor  requirements  can¬ 
not  be  estimated  solely  from  historical  data,  but  depend  on  the  specific  work  involved.  Histori¬ 
cal  activity  durations  will  certainly  not  represent  minimum  time  assignments.  Due  to  the 
assumption  of  constant  activity  loading,  the  minimum  time  assignments,  together  with  the 
activity  labor  requirements,  determine  the  maximum  crew  size  assignable  to  each  activity. 
Known  crew  size  constraints  may  actually  be  the  basis  for  the  minimum  time  assignment  esti¬ 
mates. 

While  optimal  solutions  cannot  be  generated,  considerable  loading  improvement  of  ini¬ 
tially  selected  schedules  can  be  made.  The  effect  of  varying  peak  interval  threshholds  and  mul¬ 
tiple  iteration  weighting  is  not  completely  understood.  Their  effect  will  depend  on  the  structure 
of  the  network.  This  is  most  likely  the  reason  for  the  differences  in  performance  between 
experiments  (b)  and  (c). 

Elimination  of  all  slack  from  the  network  obviously  increases  the  risk  of  project  slippage. 
Additional  constraints  can  be  included  to  retain  some  amount  of  slack  between  milestones.  In 
some  cases,  the  final  activity  time  assignments  were  unreasonably  large.  Time  assignment  upper 
bounds  could  remedy  the  problem  of  overstretched  activities. 

Varying  activity  durations  (replanning)  is  an  alternative  to  varying  activity  starting  dates 
(rescheduling)  as  a  means  of  resource  leveling.  However,  replanning  is  not  proposed  as  a  com¬ 
plete  substitute  for  rescheduling,  m  fact  some  rescheduling  of  the  best  replanning  solutions 
obtained  did  improve  resource  loading,  albeit  slightly.  Nonetheless,  we  submit  that  replanning 
of  activities  is  a  powerful  and  useful  technique  for  leveling  resource  peaks  in  shipyards  and 
related  project  industries. 
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Glossary  of  Notation 


A 

a* 

<*kt 

0 

c 

ck(t) 

CPM(t) 

d, 

f tk 

u 

/* 

K 

A 

S 

sin 

nSA 

nS\ 

nSP 

p 

Pk 

S 

5, 

T 

t. 

7  , 

r  / 

(u(/),y(/)) 

V 


-  set  of  activities 

-  labor  requirement  of  activity  shop  k 

-  peak  price  weighting  factor 

-  peak  interval  threshhold  percentage 

-  constraint  set  of  P 

-  required  capacity  of  shop  k  given  time  assignment  t' 

-  CPM  schedule  computations  given  r' 

-  minimum  time  assignment  of  activity  /,  d  =  (d { . d\4\) 

-  fraction  of  lk  in  which  activity  /  operates 

-  subset  of  lk  in  which  activity  /  operates 

-  set  of  time  periods  within  0  of  ckit  ) 

-  set  of  resources 

-  set  of  critical  time  assignment  vectors 

-  set  of  activities  with  non-zero  resource  use 

-  set  of  activities  with  non-zero  peak  prices,  given  t 

-  number  of  slack  activities 

-  number  os  slack  nodes 

-  number  of  slack  paths 

-  optimization  problem 

-  unit  capacity  cost  for  resource  k 

-  slack  of  activity  i,  given  CPM  id) 

-  slack  allocation  to  activity  / ,  j  =  f  s  | . s. 4 , ) 

-  project  duration 

-  time  assignment  of  activity  /,  /  =  ( . t>A  ) 

-  event  time  of  node  y,  r  =  (r, . r  r) 

-  event  time  of  critical  node  y,  given  CPM  id) 

-  node  pair  associated  with  activity  / 

-  set  of  network  nodes 
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